在 Day01 我們討論了分散式流程的挑戰，Day04-05 則實作了第一個 Temporal Workflow。現在，讓我們稍微放慢腳步，建立一些理論基礎。

這不是為了理論而理論，而是要幫助我們在面對複雜的分散式場景時，能夠有一套共同的語言和思維框架來討論、設計與取捨。本篇將介紹兩個關鍵觀念：BASE Model 與 State Machine。

BASE Model

要理解 BASE Model，我們得先與單機系統的對比開始說起。

在單機系統中，強一致性相對容易達成：
一旦交易（Transaciton）進行 commit 時，系統就可以保證整體操作「要嘛全部成功，要嘛全部失敗」，不會出現一半成功、一半失敗的狀況。

然而，在分散式架構下，網路延遲與節點故障是常態，要維持同樣的強一致性就變得極為困難。

因應這個挑戰，eBay 架構師 Dan Pritchett 在論文中提出了 BASE Model，作為理解分散式特性與系統取捨的重要設計指導及討論框架。

[論文]Base: An Acid Alternative

BASE Model 有三個重點：

1. 基本可用 (Basically Available)
2. 軟狀態 (Soft State)
3. 最終一致性 (Eventual Consistency)

接下來，我們以前面註冊流程為例，來具體說明這三個重點：

1. 基本可用：雖然點數服務故障了，但系統至少建帳號成功了還能用，服務稍候復原可繼續，不影響流程推進。
2. 軟狀態：所有步驟不會一起同步完成，系統有暫時性的狀態，像是失敗、未執行，這樣不完整的中間狀態要「可被接受」。
3. 最終一致性：軟狀態不要求所有步驟一起完成，但流程結束時，每一個步驟都要到達「預期的」狀態。像最後送點數成功、信寄出了。

有了這三個重點作為思考的基礎，讓我們繼續往下探討。

BASE Model 原本多用於分散式資料儲存與複寫的一致性思考，強調在網路不可靠、節點常失效的情境下，如何兼顧可用性與最終一致性。但當我們把它套用在分散式流程編排時，要意識到差異：資料同步著重於「副本一致」，而流程則是「跨服務動作的推進與補償」。BASE 可以提供一個設計指導的框架，但我們還需要額外的機制（如狀態機、補償、重試）來真正落實分散式流程的可靠性。

State Machine 狀態機

除了 BASE Model 之外，第二個重要概念是狀態機（State Machine）。

在狀態機中，所有狀態及轉換行為都是先定義好的，照定義切換狀態、以及可執行的行為。

如上圖所示，這是一個極簡狀態機的例子，on, off 是狀態，會在 press button 這個行為中進行變換。

你以為沒有狀態機，其實它始終在推動一切

在系統中，不論我們是用 排程 (job scheduler) 來安排任務，還是用 事件驅動 (event-driven) 的方式去觸發下一步，其實都牽涉到「狀態的轉換」。
即便開發者沒有明確設計出一個 狀態機，這些流程背後仍然隱含著狀態的存在：

• 排程：一個任務等待被執行、正在執行、執行完成 → 這些都是狀態。
• 事件驅動：事件發生前、事件觸發中、事件處理後 → 也是一種狀態轉移。
• 收貨流程：建立 → 貨到 → 收貨 → 驗收 → 上架 → 入庫可用。
• 製造工單：排程 → 下發 → 開工 → 待檢 → 完工。
• 訂單流程：已建立 → 已付款 → 已打包 → 已出貨 → 已送達 → 已完成。

因此，只要流程涉及以上情境，就等於自然形成了一個狀態機。差別只在於：

• 顯性設計：明確定義「待處理 → 處理中 → 處理完成 → 錯誤」等狀態，每個階段的行為和轉換條件都集中在一個狀態管理模組裡。
• 隱性存在：程式只是靠旗標或布林值判斷「是否已完成」、「是否出錯」，邏輯分散在不同函式裡，沒有統一的狀態定義，但實際上仍是按狀態在切換行為。

可怕的是，我們用排程或事件驅動，可能下意識的為每一種業務流程都自行設計了一套規則(隱性存在)，造成狀態轉換邏輯缺乏統一規範，還分散在不同程式碼與服務裡，導致流程難以追蹤、除錯與維護。

舉例來說，這張圖展示的是 Activity 的狀態移轉圖，它的狀態包含 started, completed, failed, timeout, cancel。可以看到狀態移轉圖中，實際的狀態處理非常繁瑣，每加一個狀態或行為進去就要考慮是否互相影響。

正因為狀態處理如此複雜，使用 Temporal 我們就不需要再自己手動撰寫這些複雜的處理邏輯。它已經將 狀態轉換、重試機制、逾時、取消、補償 等複雜度收斂在框架裡，開發者只需要專注於描述「業務要怎麼走」的程式，就能用一種很親民、直覺的方式寫出 能自動推進流程的程式。

結語

總結來說，本篇未涉入具體實作，而是先建立分散式流程的基本定義與思維框架：

• BASE Model 提供了共同的討論語言，幫助團隊對齊重點與取捨，聚焦決策方向。
• 狀態機 則把零散的業務流程抽象為統一的狀態轉換規則，降低上手與變更成本，並加強治理與風險管控。

理解這兩個基礎觀念，能幫助我們看清流程背後的本質與限制。
以此為基礎，下一篇將進一步延伸到 狀態管理 與 流程推進 的觀念，探討如何把抽象模型真正落實到可操作的架構設計中。

不誇張的說，學習流程引擎的過程中，我最開心的是對於 BASE Model, Eventual Consistency, State Machine 這幾個核心抽象觀念多了一點認知，並轉化為能夠直接觀察和落地應用的設計思維。